What it solves

With SEP-14 the community voted to implement role-based access control in Safe{Wallet} based on the Zodiac Roles Modifier.

How this PR fixes it

This PR allows role members to use Safe{Wallet} to execute transaction from the Safe using their role. For this purpose, a new section has been added to the transaction sign/execute form, which only shows up if the connected wallet is a member of any role enabled on the Safe.

How to test it

• Deploy a Roles Modifier through the Zodiac Safe app
• Set up some permissions for a testing role, e.g. using permissions-starter-kit, apply and assign the role to an EOA using the mod's assignRoles function

Alternatively, send me your EOA address so I can assign a role in my Sepolia test setup to it.

Screenshots

A new card appears in the transaction sign/execute form only if the Safe has a Roles mod enabled and the connected wallet account is a role member.

Connected with role member wallet, permission checks pass:

Connected with role member wallet, permission checks fail:

(Status can be any value from the Roles mods' Status enum)

Checklist

• I've tested the branch on mobile 📱
• I've documented how it affects the analytics (if at all) 📊
• I've written a unit/e2e test for it (if applicable) 🧑‍💻

Implementation details

In any of the following cases, nothing will be rendered and no extra network requests will be made:

• The transaction has already been pushed to the tx service and it in the signature collection phase
• Safe is on a network without official Roles v2 support
• There are no Safe modules enabled

Otherwise we perform a fetch request against the official role subgraph for each enabled module, checking if the module is a Roles v2 mod and retrieving its role configuration (permissions and members).

We only render the new card, if the connected wallet has any roles assigned. (There can be multiple Roles mods enabled on the Safe. An address can have multiple roles assigned on each mod.)

Next step is checking if the current transaction is allowed for any role assigned to the connected wallet address:

• If the applicable permissions (matching target address and function selector) does not use a condition, we can statically determine if it allows the current transaction. No extra requests are required in this case.
• If the applicable permission uses a condition we make an RPC call through the read-only provider for evaluating it on the given call.

If any assigned role allows the call, we enable the "Execute" button. Otherwise we show the failing permission check status for the role most likely to be meant for the given transaction, "most likely" being defined by the following order:

• role allows target address and function selector
• role allows target address, but not the function selector
• role does't allow the target address